Converting electronic documents having visible objects

ABSTRACT

A method involves managing electronic documents (EDs). The method includes receiving a first request to convert an original ED including a visible object from a first format to a second format; extracting, in response to the first request, multiple attributes in the original ED specifying the visible object and required to restore the visible object in the first format; generating, by converting the original ED from the first format to the second format, a converted ED including rendering data of the visible object that is grammatically native to the second format and that is necessary to render the visible object from the second format; and embedding the attributes extracted from the original ED into metadata of the converted ED.

BACKGROUND

An electronic document (ED) often includes one or more visible objects.A visible object is an object that is created and visible to the userwhen the ED is rendered (i.e., displayed, printed, etc.). Examplevisible objects include, but are not limited to, equation objects,spreadsheet cells, and shapes. The ED includes one or more attributesspecifying/describing the visible object. These attributes are needed tocreate the visible object. Moreover, these attributes are specific tothe format of the ED.

It is not uncommon for a user to request an ED be converted from an oldformat or a first format to a new format or a second format. Althoughconversion is possible, the conversion process often discards/loses oneor more of the attributes. Accordingly, if the user (or a differentuser) ever requests the ED be reconverted from the new format back tothe old format, the visible object(s) in the unconverted ED might notappear the same as it did prior to any conversion. This interferes withthe user's viewing experience. Regardless, users still wish to convertEDs having visible objects.

SUMMARY

In general, in one aspect, the invention relates to a method formanaging electronic documents (EDs). The method comprises: receiving afirst request to convert an original ED comprising a visible object froma first format to a second format; extracting, in response to the firstrequest, a plurality of attributes in the original ED specifying thevisible object and required to restore the visible object in the firstformat; generating, by converting the original ED from the first formatto the second format, a converted ED comprising rendering data of thevisible object that is grammatically native to the second format andthat is necessary to render the visible object from the second format;and embedding the plurality of attributes extracted from the original EDinto metadata of the converted ED.

In general, in one aspect, the invention relates to a method formanaging electronic documents (EDs). The method comprises: receiving arequest to convert a converted ED to a first format from a secondformat; identifying, during a parsing of the converted ED triggered bythe request, rendering data of a visible object that is grammaticallynative to the second format and that is necessary to render the visibleobject from the second format; locating, in response to identifying therendering data of the visible object, a plurality of attributes requiredto restore the visible object in the first format within metadata of theconverted ED; and generating, by converting the converted ED from thesecond format to the first format, an unconverted ED comprising thevisible object restored using the plurality of attributes extracted fromthe metadata.

In general, in one aspect, the invention relates to a non-transitorycomputer readable medium (CRM) storing instructions for managingelectronic documents (EDs). The instructions comprising functionalityfor: receiving a first request to convert a converted ED to a firstformat from a second format; identifying, during a parsing of theconverted ED triggered by the first request, rendering data of a visibleobject that is grammatically native to the second format and that isnecessary to render the visible object from the second format; locating,in response to identifying the rendering data of the visible object, aplurality of attributes required to restore the visible object in thefirst format within metadata of the converted ED; and generating, byconverting the converted ED from the second format to the first format,an unconverted ED comprising the visible object restored using theplurality of attributes extracted from the metadata.

In one aspect, a system for managing electronic documents (EDs). Thesystem comprises: a processor; a buffer configured to store an originalED comprising a plurality of attributes specifying a visible object andrequired to restore the visible object in a first format; an extractorconfigured to extract the plurality of attributes from the original ED;a conversion engine executing on the processor and configured togenerate a converted ED comprising rendering data of the visible objectby converting the original document from the first format to a secondformat, wherein the rendering data is grammatically native to the secondformat and necessary to render the visible object from the secondformat; and an embedding engine configured to embed the plurality ofattributes extracted from the original ED into metadata of the convertedED.

Other aspects of the invention will be apparent from the followingdescription and the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows a system in accordance with one or more embodiments of theinvention.

FIG. 2A and FIG. 2B show flowcharts in accordance with one or moreembodiments of the invention.

FIG. 3A, FIG. 3B, and FIG. 3C show examples in accordance with one ormore embodiments of the invention.

FIG. 4 shows a computer system in accordance with one or moreembodiments of the invention.

DETAILED DESCRIPTION

Specific embodiments of the invention will now be described in detailwith reference to the accompanying figures. Like elements in the variousfigures are denoted by like reference numerals for consistency.

In the following detailed description of embodiments of the invention,numerous specific details are set forth in order to provide a morethorough understanding of the invention. However, it will be apparent toone of ordinary skill in the art that the invention may be practicedwithout these specific details. In other instances, well-known featureshave not been described in detail to avoid unnecessarily complicatingthe description.

In general, embodiments of the invention provide a system and method formanaging EDs. Following a request to convert an original ED having avisible object from a first format to a second format, the attributes inthe original ED specifying the visible object are extracted. Theseattributes may be used in the future to restore (i.e., recreate) thevisible object in the first format. Then, a converted ED is generated byconverting the original ED from the first format to the second format.The converted ED may include metadata and rendering data that isgrammatically native to the second format and is necessary to render animage of the visible object. The previously extracted attributes areembedded in the metadata of the converted ED. For example, the extractedattributes may be embedded in metadata within an invisible layer of theconverted ED. If a request is later received to convert the converted EDfrom the second format back to the first format, an unconverted ED willbe generated by converting the converted ED from the second format backto the first format. The attributes will subsequently be located in themetadata of the converted ED, and then used to restore the originalobject in the first format for the unconverted ED.

FIG. 1 shows a system (110) in accordance with one or more embodimentsof the invention. As shown in FIG. 1, the system (110) has multiplecomponents including a buffer (112), an extractor (114), a conversionengine (118), and an embedding engine (116). Each of these components(112, 114, 116, 118) may be located on the same hardware device (e.g.,personal computer (PC), a desktop computer, a mainframe, a server, atelephone, a kiosk, a cable box, a personal digital assistant (PDA), anelectronic reader, a smart phone, a tablet computer, etc.) or may belocated on difference hardware devices connected using a network havingwired and/or wireless segments. In one or more embodiments of theinvention, the system (110) inputs the original ED (102) and outputs theconverted ED (104). In one or more embodiments of the invention, thesystem (110) inputs the converted ED (104), and outputs the unconvertedED (106).

In one or more embodiments of the invention, the original ED (102)includes one or more visible objects to be displayed/printed on oracross one or more pages. A visible object is an object that is createdand visible to the user when the original ED (102) is rendered (i.e.,displayed, printed, etc.). Example visible objects include, but are notlimited to, equation objects, spreadsheet cells, and shapes. Theoriginal ED (102) includes one or more attributes specifying/describingthe visible object. In the case of spreadsheet cells, these attributesmay include the number of rows, the number of columns, the sizes of thecells, the functions/equations in the cells that calculate the value ofeach cell, etc. In the case of a shape, the attributes may include glow,shadow, and reflection values, etc. In the case of an equation object,the attributes may include the parameters/variables in the equation, theoperators, etc. These attributes are needed to create the visibleobject. Moreover, these attributes are specific to the format of theoriginal ED (102).

In one or more embodiments of the invention, the original ED (102) isrepresented/defined using a document markup language (e.g., opendocument format (ODF), office open XML (OOXML), etc.). Accordingly, theattributes of the visible object(s) in the original ED (106) may berecorded within the tags of the document markup language.

In one or more embodiments of the invention, the converted ED (104) isthe original ED (102) in a different format. For example, the convertedED (104) may be in the portable document format (PDF). The converted ED(104) is generated by converting the original ED (102) from its initialformat (e.g., OOXML) to a new format (e.g., PDF).

In one or more embodiments of the invention, the converted ED (104)includes rendering data that is necessary to render an image of thevisible object in the original ED (102). When the converted ED (104) isrendered (i.e., printed, displayed, etc.), the visible object is notcreated from the attributes. Instead, the existing rendering data of thevisible object is used to render the converted ED (104). In one or moreembodiments of the invention, the converted ED (104) includes metadataembedded with the attributes of the visible object (104) extracted fromthe original ED (102) (discussed below). However, these embeddedattributes are not needed to render the converted ED (104).

As discussed above, the converted ED (104) may be in the PDF. In suchembodiments, the converted ED (104) may include both a visible layerthat will be visible to the user when the converted ED (104) isrendered, and an invisible layer that is not visible to the user whenthe converted ED (104) is rendered. The rendering data of the visibleobject may be located within the visible layer. The metadata embeddedwith the attributes of the visible object may be located within theinvisible layer. In one or more embodiments of the invention, thevisible layer and the invisible layer overlap, and the attributes of thevisible object are located directly above or directly below therendering data of the visible object.

In one or more embodiments of the invention, the unconverted ED (106) isthe converted ED (104) in the same format as the original ED (102)(e.g., OOXML). The unconverted ED (106) is generated by converting theconverted ED (104) from its format (e.g., PDF), to the format of theoriginal ED (102) (i.e., OOXML). Like the original ED (102), theunconverted ED (106) includes the attributes of the visible object, andthese attributes are used to create the visible object when theunconverted ED (106) is rendered. In other words, the unconverted ED(106) includes the visible object restored in the first format using theplurality of attributes from the metadata of the converted ED (104)(discussed below).

In one or more embodiments of the invention, the system (110) includesthe buffer (112). The buffer (112) may correspond to any type of memoryor long-term storage (e.g., hard drive) and may be of any size. In oneor more embodiments of the invention, the original ED (102) is stored inthe buffer (112) following a request to convert the original ED (102)from a first format (e.g., OOXML) to a second format (e.g., PDF). In oneor more embodiments of the invention, the converted ED (104) is storedin the buffer (112) following a request to convert the converted ED(104) from the second format to the first format.

In one or more embodiments of the invention, the system (110) includesthe extractor (114), which may be a software module stored in a memoryof the system such as a Read Only Memory (ROM), a Hard Disk Drive (HDD),and so on, and executed by a processor of the system, such as a CentralProcessing Unit (CPU), Micro Processing Unit (MPU), and so on. Theextractor (114) is configured to identify (e.g., via parsing) visibleobjects in the original ED (102) while the original ED (102) is storedin the buffer (112). The extractor (114) is further configured toextract the attributes of the visible objects. Extraction does notrequired removal of the attributes from the original ED (102). Instead,extraction may correspond to the recording of attributes that arepresent in the original ED (102) and the values of the attributes. Inone or more embodiments of the invention, the extractor (114) includes alist with standard visible objects and their attributes that can becompared against the original ED (102) to identify attributes forextraction.

In one or more embodiments of the invention, the extractor (114) isconfigured to identify (e.g., via parsing) rendering data of eachvisible object in the converted ED (104) while the converted ED (104) isstored in the buffer (112). The extractor (114) is further configured tothen locate the attributes corresponding to each visible object in themetadata of the converted image (104). As discussed above, the renderingdata of each of the visible objects may be located within a visiblelayer of the converted ED (104), while the attributes of each of thevisible objects may be located above or below the correspondingrendering data in the invisible layer of the converted ED (104).

In one or more embodiments of the invention, the system (110) includesthe conversion engine (118), which may be a software module stored inthe memory and executed by the processor. The conversion engine (118) isconfigured to generate the converted ED (104) by converting the originalED (102) from its format (e.g., OOXML) to a different format (e.g.,PDF). The conversion process may include generating rendering data ofthe visible objects in the original ED (102) for inclusion in theconverted ED (104). The rendering data of each visible image may begrammatically native to the different format. As discussed above, therendering data may be used to render the converted ED (104).

In one or more embodiments of the invention, the conversion engine (118)is configured to generate the unconverted ED (106) from the converted ED(104). The conversion process may include restoring (i.e., recreating)visible objects in the first format using the attributes extracted fromthe metadata of the converted ED (104).

In one or more embodiments of the invention, the system (110) includesthe embedding engine (116), which may be a software module stored in thememory and executed by the processor. The embedding engine (116) isconfigured to embed visible object attributes extracted from theoriginal ED (102) into the metadata of the converted ED (104). Asdiscussed above, the converted ED (104) may include two overlappinglayers: a visible layer with the rendering data of the visible objectsand an invisible layer with the metadata thereof. The embedding engine(116) may embed the attributes of a visible object with the metadataimmediately above the rendering data of the visible object (if theinvisible layer is above the visible layer), or below the rendering dataof the visible object (if the invisible layer is below the visiblelayer).

FIG. 2A shows a flowchart in accordance with one or more embodiments ofthe invention. The process shown in FIG. 2A may be executed, forexample, by one or more components (e.g., extractor (114), embeddingengine (116), conversion engine (118)) discussed above in reference toFIG. 1. In case the one more components are configured as softwaremodules, the computer program codes are stored in the memory of thesystem (110), and the process is carried out by the processor's readingout the program codes and executing the codes. One or more steps shownin FIG. 2A may be omitted, repeated, and/or performed in a differentorder among different embodiments of the invention. Accordingly,embodiments of the invention should not be considered limited to thespecific number and arrangement of steps shown in FIG. 2A.

Initially, a request to convert an original ED from a first format to asecond format is received (STEP 205). The request may be received from auser or from an executing software application. As discussed above, theoriginal ED includes one or more visible objects to be displayed/printedon or across one or more pages. As also discussed above, the firstformat may be the document markup language OOXML, and the second formatmay be PDF.

In STEP 210, the attributes specifying the visible object are extractedfrom the original ED. As discussed above, a visible object is an objectthat is created from attributes specified in the original ED when theoriginal ED is rendered (i.e., displayed, printed, etc.). Accordingly,these attributes may be used in the future to restore (i.e., recreate)the visible object in the first format. The visible object and itsattributes may be identified during a parsing of the original EDtriggered by the request (STEP 205). Moreover, extraction need notrequire removal of the attributes from the original ED. Instead,extraction may correspond to the recording of visible object(s) and itsattributes that are present in the original ED and the values of theattributes. In one or more embodiments of the invention, there exists alist with standard visible objects and their attributes that can becompared against the original ED to identify attributes for extraction.

In STEP 215, a converted ED is generated. The converted ED is generatedby converting the original ED from the first format (e.g., OOXML) to thesecond format (e.g., PDF). The conversion process may include generatingrendering data of the visible objects in the original ED for inclusionin the converted ED. When the converted ED is rendered (i.e., printed,displayed, etc.), the visible object is not created from the attributes.Instead, the existing rendering data of the visible object is used torender the converted ED.

In STEP 220, the attributes extracted from the original ED (STEP 210)are embedded in metadata of the converted ED. As discussed above, theconverted ED may be in the PDF. In such embodiments, the converted EDmay include both a visible layer that will be visible to the user whenthe converted ED is rendered, and an invisible layer that is not visibleto the user when the converted ED is rendered. The rendering data of thevisible object may be located within the visible layer. The metadataembedded with the attributes of the visible object may be located withinthe invisible layer. However, the embedded attributes are not needed torender the converted ED. In one or more embodiments of the invention,the visible layer and the invisible layer overlap, and the attributes ofthe visible object are located directly above or directly below therendering data of the visible object.

FIG. 2B shows a flowchart in accordance with one or more embodiments ofthe invention. The process shown in FIG. 2A may be executed, forexample, by one or more components (e.g., extractor (114), embeddingengine (116), conversion engine (118)) discussed above in reference toFIG. 1. In case the one more components are configured as softwaremodules, the computer program codes are stored in the memory of thesystem (110), and the process is carried out by the processor's readingout the program codes and executing the codes. One or more steps shownin FIG. 2B may be omitted, repeated, and/or performed in a differentorder among different embodiments of the invention. Accordingly,embodiments of the invention should not be considered limited to thespecific number and arrangement of steps shown in FIG. 2B. One or moreof the steps in FIG. 2B may be executed at some future point after STEP220 in FIG. 2A.

Initially, a request to convert a converted document from the secondformat to the first format is received (STEP 250). The request may bereceived from a user or from an executing software application. Asdiscussed above, the first format may be the document markup languageOOXML, and the second format may be PDF.

In STEP 255, rendering data of a visible object is identified within theconverted ED. The rendering data of the visible object may be identifiedby parsing the converted ED in response to the request (STEP 250). Asdiscussed above, the converted ED may be in PDF. In such embodiments,any rendering data of visible objects may be located within a visiblelayer of the converted ED.

In STEP 260, the attributes corresponding to the visible object arelocated within the metadata of the converted ED. As discussed above, theconverted ED may be in PDF. In such embodiments, the metadata may belocated in an invisible layer of the converted ED. The invisible layerand the visible layer may overlap. Moreover, the attributes of a visibleobject may be embedded in metadata located directly below or directlyabove the image of the visible object. Once located, these attributesmay be extracted to generate the unconverted ED (described below).

In STEP 265, an unconverted ED is generated. The unconverted ED isgenerated by converting the converted ED from the second format (e.g.,PDF) to the first format (e.g., OOXML). The conversion process mayinclude restoring the visible objects in the first format using theattributed extracted from the metadata. In other words, the unconvertedED comprises the visible objects restored (i.e., recreated) in the firstformat using the attributes extracted from the metadata (STEP 260). Likethe original ED, the unconverted ED includes the attributes of thevisible object, and these attributes are used to create the visibleobject when the unconverted ED is rendered.

FIG. 3A and FIG. 3B show an example in accordance with one or moreembodiments of the invention. As shown in FIG. 3A, there exists anoriginal ED (302) in OOXML format. The original ED (302) has multipleattributes (308) specifying a visible object. Specifically, the multipleattributes specify an equation object and the multiple attributes arerecorded in tags. When the original ED (302) is rendered (i.e., RenderedOriginal ED (304)), the visible object (306) is created from theattributes (308) and is visible to the user.

Still referring to FIG. 3A, assume a request is received to convert theoriginal ED (302) from OOXML to PDF. In response to the request, theconverted ED (316) is generated. The converted ED (316) has a visiblelayer (322) and an invisible layer (326) that overlap, with the visiblelayer (322) on top of the invisible layer (326). The conversion processincludes generating rendering data of the visible object (324) andplacing it within the visible layer (322) of the converted ED (316). Forinstance, an image file of the visible object (324), such as GIFF, TIFF,JPEG, and so on, is generated as the rendering data and is placed in thevisible layer (322) of the converted ED (316). The attributes (308) areembedded in metadata within the invisible layer (326) of the convertedED (316). Moreover, the embedded attributes (328) are positioned withinthe invisible layer (326) beneath the image of the visible object (324)within the visible layer (322). Or, instead of or in addition to usingthe physical location, the embedded attributes (328) may be associatedwith the visible object (324) by providing a table in the converted ED(316). Although the converted ED (316) includes the embedded attributes(328), it is the rendering data of the visible object (324) that areneeded to render the converted ED (316). In other words, the embeddedattributes (328) are not needed to render the converted ED (316). Itshould be appreciated that the rendering data of the visible object(324) in the second format is not necessarily in a format of an imagefile as far as the rendering data is grammatically native to the secondformat so that an image of the visible object (324) can be rendered fromthe converted ED (316).

Now referring to FIG. 3B, at some future point, a request is received toconvert the converted ED (316) from PDF back to OOXML. In response tothe request, the unconverted ED (332) is generated. During theconversion process, in response to identifying the rendering data of thevisible object (324), the corresponding embedded attributes (328) arelocated in the invisible layer (326). These embedded attributes (328)are used to restore (i.e., recreate) the visible object (306) in OOXML.As shown in FIG. 3B, the unconverted ED (322), like the original ED(302), includes the attributes (308). Moreover, the attributes (308) arerequired to create the visible object (306) when the unconverted ED(332) is rendered (i.e., Rendered Unconverted ED (334)).

Although the example(s) in FIG. 3A and FIG. 3B has focused on a visibleobject that is an equation object, those skilled in the art, having thebenefit of this detailed description, will appreciate that that thecells of a spreadsheet may also be a visible object(s). FIG. 3C shows anexample in accordance with one or more embodiments of the invention. Asshown in FIG. 3C, there exists a visible object (384) that correspondsto a spreadsheet with cells. Assume this visible object (384) exists inan original ED. The original ED would include attributes needed tocreate the visible object (384) when the original ED is rendered.Specifically, these attributes may include the equations/formulas ineach cell that are used to calculate the value of the cell, the numberof rows, the number of columns, the height and widths of the rows andcolumns, etc.

Still referring to FIG. 3C, assume a request is received to convert theoriginal ED having the visible object (388) from OOXML to PDF. Inresponse to the request, a converted ED is generated. During theconversion process, rendering data of the visible object (386) iscreated and placed within the visible layer of the converted ED. In thisparticular example, the rendering data may include text data of thevalue to be displayed in the cell and the font and style data designedin the cell. Moreover, the attributes of the visible object (384) areextracted from the original ED and embedded in the metadata of theconverted ED. In this particular example, the metadata of the visibleobject may include tags related to the equations/formulas in the cell.It is the rendering data of the visible object (386), not the embeddedattributes (388), that are used to render the converted ED. However, theembedded attributes (388) may be used at a future point to restore thevisible objects in the OOXML format (e.g., in response to a request toconvert the converted ED from PDF back to OOXML).

Embodiments of the invention may have one or more of the followingadvantages: the ability to restore a visible object in its originalformat from a converted ED that is in a different format; the ability toembed attributes of a visible object in metadata of the converted ED;the ability to use the invisible layer to store the attribute embeddedmetadata below or above rendering data of visible objects, the abilityto improve the experience of a user viewing the unconverted ED; etc.

Embodiments of the invention may be implemented on virtually any type ofcomputing system regardless of the platform being used. For example, thecomputing system may be one or more mobile devices (e.g., laptopcomputer, smart phone, personal digital assistant, tablet computer, orother mobile device), desktop computers, servers, blades in a serverchassis, or any other type of computing device or devices that includesat least the minimum processing power, memory, and input and outputdevice(s) to perform one or more embodiments of the invention. Forexample, as shown in FIG. 4, the computing system (400) may include oneor more computer processor(s) (402), associated memory (404) (e.g.,random access memory (RAM), cache memory, flash memory, etc.), one ormore storage device(s) (406) (e.g., a hard disk, an optical drive suchas a compact disk (CD) drive or digital versatile disk (DVD) drive, aflash memory stick, etc.), and numerous other elements andfunctionalities. The computer processor(s) (402) may be an integratedcircuit for processing instructions. For example, the computerprocessor(s) may be one or more cores, or micro-cores of a processor.The computing system (400) may also include one or more input device(s)(410), such as a touchscreen, keyboard, mouse, microphone, touchpad,electronic pen, or any other type of input device. Further, thecomputing system (400) may include one or more output device(s) (408),such as a screen (e.g., a liquid crystal display (LCD), a plasmadisplay, touchscreen, cathode ray tube (CRT) monitor, projector, orother display device), a printer, external storage, or any other outputdevice. One or more of the output device(s) may be the same or differentfrom the input device(s). The computing system (400) may be connected toa network (412) (e.g., a local area network (LAN), a wide area network(WAN) such as the Internet, mobile network, or any other type ofnetwork) via a network interface connection (not shown). The input andoutput device(s) may be locally or remotely (e.g., via the network(412)) connected to the computer processor(s) (402), memory (404), andstorage device(s) (406). Many different types of computing systemsexist, and the aforementioned input and output device(s) may take otherforms.

Software instructions in the form of computer readable program code toperform embodiments of the invention may be stored, in whole or in part,temporarily or permanently, on a non-transitory computer readable mediumsuch as a CD, DVD, storage device, a diskette, a tape, flash memory,physical memory, or any other computer readable storage medium.Specifically, the software instructions may correspond to computerreadable program code that when executed by a processor(s), isconfigured to perform embodiments of the invention.

Further, one or more elements of the aforementioned computing system(400) may be located at a remote location and connected to the otherelements over a network (412). Further, embodiments of the invention maybe implemented on a distributed system having a plurality of nodes,where each portion of the invention may be located on a different nodewithin the distributed system. In one embodiment of the invention, thenode corresponds to a distinct computing device. Alternatively, the nodemay correspond to a computer processor with associated physical memory.The node may alternatively correspond to a computer processor ormicro-core of a computer processor with shared memory and/or resources.

While the invention has been described with respect to a limited numberof embodiments, those skilled in the art, having benefit of thisdisclosure, will appreciate that other embodiments can be devised whichdo not depart from the scope of the invention as disclosed herein.Accordingly, the scope of the invention should be limited only by theattached claims.

What is claimed is:
 1. A method for managing electronic documents (EDs),comprising: receiving a first request to convert an original EDcomprising a visible object from a first format to a second format;extracting, in response to the first request, a plurality of attributesin the original ED specifying the visible object and required to restorethe visible object in the first format; generating, by converting theoriginal ED from the first format to the second format, a converted EDcomprising rendering data of the visible object that is grammaticallynative to the second format and that is necessary to render the visibleobject from the second format; and embedding the plurality of attributesextracted from the original ED into metadata of the converted ED.
 2. Themethod of claim 1, wherein the converted ED further comprises: a visiblelayer with the rendering data of the visible object; and an invisiblelayer with the metadata comprising the plurality of attributes, whereinthe visible layer and the invisible layer overlap, and wherein therendering data in the visible layer is located above the plurality ofattributes in the invisible layer.
 3. The method of claim 2, wherein thefirst format is Open Office XML (OOXML), and wherein the second formatis portable document format (PDF).
 4. The method of claim 1, wherein thevisible object comprises a plurality of spreadsheet cells, and whereinthe plurality of attributes comprises equation data corresponding to theplurality of spreadsheet cells.
 5. The method of claim 1, wherein thevisible object is an equation object.
 6. The method of claim 1, whereinthe visible object comprises a shape, and wherein the plurality ofattributes comprises at least one shape effect selected from a groupconsisting of glow, shadow, and reflection.
 7. The method of claim 1,further comprising: receiving a second request to convert the convertedED from the second format to a first format; identifying, during aparsing of the converted ED triggered by the second request, therendering data of the visible object; locating, in response toidentifying the rendering data of the visible object, the plurality ofattributes required to restore the visible object in the first formatwithin the metadata of the converted ED; and generating, by convertingthe converted ED from the second format to the first format, anunconverted ED comprising the visible object restored using theplurality of attributes extracted from the metadata.
 8. A method formanaging electronic documents (EDs), comprising: receiving a request toconvert a converted ED to a first format from a second format;identifying, during a parsing of the converted ED triggered by therequest, rendering data of a visible object that is grammatically nativeto the second format and that is necessary to render the visible objectfrom the second format; locating, in response to identifying therendering data of the visible object, a plurality of attributes requiredto restore the visible object in the first format within metadata of theconverted ED; and generating, by converting the converted ED from thesecond format to the first format, an unconverted ED comprising thevisible object restored using the plurality of attributes extracted fromthe metadata.
 9. The method of claim 8, wherein the converted ED furthercomprises: a visible layer with the rendering data of the visibleobject; and an invisible layer with the metadata comprising theplurality of attributes, wherein the visible layer and the invisiblelayer overlap.
 10. The method of claim 8, wherein the first format isOpen Office XML (OOXML), and wherein the second format is portabledocument format (PDF).
 11. A non-transitory computer readable medium(CRM) storing instructions for managing electronic documents (EDs), theinstructions comprising functionality for: receiving a first request toconvert a converted ED to a first format from a second format;identifying, during a parsing of the converted ED triggered by the firstrequest, rendering data of a visible object that is grammatically nativeto the second format and that is necessary to render the visible objectfrom the second format; locating, in response to identifying therendering data of the visible object, a plurality of attributes requiredto restore the visible object in the first format within metadata of theconverted ED; and generating, by converting the converted ED from thesecond format to the first format, an unconverted ED comprising thevisible object restored using the plurality of attributes extracted fromthe metadata.
 12. The non-transitory CRM of claim 11, the instructionsfurther comprising functionality for: receiving a second request toconvert an original ED comprising the visible object from the firstformat to the second format; extracting the plurality of attributes inthe original ED specifying the visible object and required to restorethe visible object in the first format; generating, by converting theoriginal ED from the first format to the second format, the converted EDcomprising the rendering data of the visible object; and embedding theplurality of attributes extracted from the original ED into the metadataof the converted ED.
 13. The non-transitory CRM of claim 11, wherein theconverted ED further comprises: a visible layer with the rendering dataof the visible object; and an invisible layer with the metadatacomprising the plurality of attributes.
 14. The non-transitory CRMmethod of claim 13, wherein the visible layer and the invisible layeroverlap, and wherein the rendering data in the visible layer is locatedabove the plurality of attributes in the invisible layer.
 15. Thenon-transitory CRM of claim 11, wherein the first format is Open OfficeXML (OOXML), and wherein the second format is portable document format(PDF).
 16. A system for managing electronic documents (EDs), comprising:a processor; a buffer configured to store an original ED comprising aplurality of attributes specifying a visible object and required torestore the visible object in a first format; an extractor configured toextract the plurality of attributes from the original ED; a conversionengine executing on the processor and configured to generate a convertedED comprising rendering data of the visible object by converting theoriginal document from the first format to a second format, wherein therendering data is grammatically native to the second format andnecessary to render the visible object from the second format; and anembedding engine configured to embed the plurality of attributesextracted from the original ED into metadata of the converted ED. 17.The system of claim 16, wherein: the extractor is further configured tolocate the plurality of attributes specifying the visible object withinthe metadata of the converted ED and extract the plurality of attributesfrom the metadata; and the conversion engine is further configured togenerate, by converting the converted ED from the second format to thefirst format, an unconverted ED comprising the visible object restoredusing the plurality of attributes extracted from the metadata.
 18. Thesystem of claim 16, wherein the visible object is at least one selectedfrom a group consisting of an equation object, a plurality ofspreadsheet cells, and a shape.
 19. The system of claim 16, wherein theconverted ED further comprises: a visible layer with the rendering dataof the visible object; and an invisible layer with the metadatacomprising the plurality of attributes, wherein the visible layer andthe invisible layer overlap.
 20. The system of claim 19, wherein thefirst format is Open Office XML (OOXML), and wherein the second formatis portable document format (PDF).